Check out Glinski's Hexagonal Chess, our featured variant for May, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

LatestLater Reverse Order EarlierEarliest
[Subject Thread] [Add Response]
Rich Hutnik wrote on Thu, Oct 23, 2008 06:01 PM UTC:
Hello Fergus.

I am of the belief a major issue that would need to be worked out, is
people determining what the protocols for communication will be and
agreeing to use them.

An approach I am seeing that could work, would be to break down each
action distinctly.  Selecting a position is one.  Then selection which
piece(s) in an position to move would be another.  After this, where to
move the piece(s) to follows.  Then you resolve the results of the action
of moving to (like a pawn promotion).  Then you see if there is any other
moves or a pass action.

Between the interface and the play area is each discrete actions that are
passed back and forth.

H. G. Muller wrote on Thu, Oct 23, 2008 05:54 PM UTC:
Does Zillions recognize and award the Bishop pair? Or do the values you
give represent an average of the paired nd unpaired Bishop?

Exchanging the first B (so you break the pair) against N+P turned out to be an equal trade in Capablanca. It seems strange that the difference goes down. Based on GM games in normal Chess, the B-N difference increases as more Pawns disappear (as one would expect towards the end-game), exact equality occurring if each side has 5 Pawns.

M Winther wrote on Thu, Oct 23, 2008 05:37 PM UTC:
Muller, it is interesting to note the 0.5 difference between bishop and
knight in Capablanca's chess. An untweaked Zillions regards the
difference as 0.523 in the beginning and as 0.446 in the middlegame. Both
pieces increase their dynamic value, but the value of the knight increases
more, having to do with the centralization of the knight. More than +0.5 is
regarded as a clear advantage, but I cannot accept that the party who
exchanges a knight for a bishop has almost achieved a clear advantage.

In my own slightly tweaked version the difference is 0.499(!) in the
beginning, but the difference is reduced in the middlegame, to 0.279. But
a 0.3 points difference is significant enough. I have always though of
this as a drawback to Capablanca's chess. That's why I invented the
Donkey and the Kwagga, which are equally valuable as a bishop on the 8x10
board.
/Mats

H. G. Muller wrote on Thu, Oct 23, 2008 04:31 PM UTC:
M. Winther:
| Another method is when I pit the new piece(s) against a different 
| army of known pieces. If the result is equal after a number of games, 
| then I regard the piece as equally valuable as its counterpart in the 
| other army. So this is a practical testing method of determining piece 
| values, which I let Zillions do automatically.

This is essentially the same way I do it. (Except that I do not use
Zillions, but Fairy-Max or Joker80.) Try to set up nearly equivalent piece
combinations, by making as few substitutions as possible in the array
defining the context. If a side wins modestly, I give it additional Pawns
odds to swing the balance, and gauge the remaining difference compared to
the Pawn value.

| I have found that when a piece is valued, perhaps, 2.5, or 3.5, 
| then it tends to converge around the piece value 3, e.g. the same 
| as a bishop or knight. The point is, namely, that the new piece can 
| threaten exchange, or vice versa. And the threatened party cannot 
| withdraw for strategical or positional reasons. 

This effect is certainly present to a certain extent, but not as large as
you make it out to be here. A difference of 5 centiPawn often occurs, and
is very rea. Thi is well confirmed in normal Chess, where the value of the
first Bishop to be captured is 50cP (the B-pair bonus) above that of any
Knight. This can be based on GM games, and it is also what I find in
computer self-play. On 10x8 a 50cP difference exists between B and N even
in absense of other Bishops, and not telling the computer they were equal
caused a neary 100 Eo drop in playing strength in results against other,
unrelated engines.

But it is true that for much smaller differences, like 20cP or less, a
computer often performs better if you make it underestimate the
difference.

| Hence the piece values converge around the nodes of 3 and 5. Remember 
| that also the formally higher valued piece can often threaten exchange 
| to achieve a positional or tactical goal. 

The tendency to control willingness to sacrifice should not be tuned by
the piece values, but by the value of the positional goal.

| So, they are worth the same due to practical factors, while they are
| *practically* interchangeable*. Obviously, in an equal army variant 
| both players can exchange the new piece, and the remaining position 
| is still equal. Hence, the new piece is equally valuable as a light 
| piece. 

I am not sure what you want to say with this.

| To really introduce a different valued piece, then it must by 
| pinpointed at 4, I suppose. 

I think the B-N base-value difference in Capablanca variants clearly shows
that this is not true. Ignoring a difference of 50cP really causes a large
drop in strength.

| I don't know if this phenomenon can be mathematically represented. 
| It depends on the piece congestion, i.e. size of board, and whether 
| the nearly equal valued pieces are long-shooting, i.e. whether they 
| can easily be used to make an exchange.

All these effects are included in the empirical value determination by
playing games. Fortunately self-play results are not very sensitive to
wrong piece values (unlike playing wrong piece values against correct
ones, wich makes you take a big hit). So if the values change in later
game phases, so that values tuned to the starting position no longer
strictly apply, the results are not significantly corrupted by this. So
although it would be better to use an engine with  very advanced
evalution, taking material-interaction terms into account next to the
piece values, this is not strictly needed for measuring the piece values.
(But it would be essential for measring the more subtle interaction
effects; if these are not recognized at all, they are simply randomly
squadered, and an initial unrecognized advantages might not survive long
enogh to affect the result. E.g if you play paired Bishops against
unpaired Bishops (i.e. on the same color) with in engine that does not
score the B-pair, the first Bishop is very likely to be traded so early,
that the B-pair advantage does not get the time to affect the score.

M Winther wrote on Thu, Oct 23, 2008 02:53 PM UTC:
Muller, obviously you know the mathematics. But I question the relevance of
determining piece value to the decimal. The method I have used is to see
how well a piece fares in a Western piece context, e.g. how many moves
does it make compared with the other pieces (i.e. how useful it is).
Another method is when I pit the new piece(s) against a different army of
known pieces. If the result is equal after a number of games, then I
regard the piece as equally valuable as its counterpart in the other army.
So this is a practical testing method of determining piece values, which I
let Zillions do automatically.

I have found that when a piece is valued, perhaps, 2.5, or 3.5, then it
tends to converge around the piece value 3, e.g. the same as a bishop or
knight. The point is, namely, that the new piece can threaten exchange, or
vice versa. And the threatened party cannot withdraw for strategical or
positional reasons. Hence the piece values converge around the nodes of 3
and 5. Remember that also the formally higher valued piece can often
threaten exchange to achieve a positional or tactical goal. 

So, they are worth the same due to practical factors, while they are
*practically* interchangeable*. Obviously, in an equal army variant both
players can exchange the new piece, and the remaining position is still
equal. Hence, the new piece is equally valuable as a light piece. To
really introduce a different valued piece, then it must by pinpointed at
4, I suppose. 

I don't know if this phenomenon can be mathematically represented. It
depends on the piece congestion, i.e. size of board, and whether the
nearly equal valued pieces are long-shooting, i.e. whether they can easily
be used to make an exchange.
/Mats

H. G. Muller wrote on Thu, Oct 23, 2008 11:07 AM UTC:
| No, that doesn't follow. You could win me over by providing better 
| graphics. Besides, all I want is the ability for me to provide you 
| with better graphics. I am not asking you to provide any additional 
| graphics. I have the graphics. I want the ability to use them with 
| Winboard.

It would be very nice to add other graphics to WinBoard, but I want to
avoid unlimited bloating, so I think te requirements should stay within
reason. In particular I want to avoid providing a zillion different
mechanisms for doing exactly the same thing, especially if each of them
would only work in different situations. (E.g. colors working only with
bitmaps, and scaling working only with fonts.)

| No, it would not be a waste of time at all. The only programs with 
| the kind of graphics capability I want are Zillions of Games and a 
| couple Chinese Chess programs with customizable graphics. Everything 
| else comes up short, even ChessV, because it doesn't use images for 
| boards.

Well, non of the graphics code in WinBoard is of my own hand, but I have
taken a peek at it. At the WinBoard part at least. This code is platform
dependent, and the Linux version, xboard, has completely different code
for this. WinBoard has built-in bitmaps (2-color for black pieces, 3-color
for white, one of the colors being 'transparent') for each size, and
scalable tri-color font-based pieces which are customizable. Xboard has
2-color built-in 'bitmaps' (transparent + color; no outline), and
4-color 'pixmaps' (including the square in the 4th color, so that a
duplicate set is needed), both non-scalable, but both customizable.

I consider it a very undesirable that WinBoard and xboard are so different
here, but phasing out customizability options in which sers might have
heavily invested is something that is 'not done'. My prevference would
be to switch to a single, platform-independent graphics package and format
for internal use (built-ins), and convert the obsolete customization input
formats to this internal format. In WinBoard things basically lready work
that way, MicroSoft monochrome bitmaps being the internal format (using 2
layers to create the white pieces), and font-based rendering converting
the given font to such bitmaps.

In the WinBoard graphcs code, there seems noting that resticts it to
monochrome bitmaps; the number of colors is part of the bitmap definition
in MicroSoft format. I am not sure if the MicroSoft graphics library
supports transparent color. Currently this is emlated by anding and orring
bitmaps together, wchich in black and white has a well-defined effect, but
with multiple bits per pixel might not always do what you want. If a
solution can be found for this, there would be nothing against using
many-color bitmaps as internal format.

Such bitmaps would then also be suitable as customization input (like
xboard already does for monochrome bitmaps), PROVIDED an acceptable way
for scaling the user input to the current disply size can be found.

Of course people having very special desires that are to uncommon to make
it likely to be supported can always customize their own private version
of WinBoard by changing the built-in bitmaps, and recompiling it. WinBoard
is open source.

| That is not an option. It is a commercial program that only plays Shogi
| and does not include any graphics for the Kamikaze piece.

That is what I mean. If WinBoard were the only program that remotely
supports what you want to do, you would use it despite the perceived minor
shortcomings.

| Since Winboard already supports fonts, you do have the option of 
| using fonts instead of rescaled bitmaps. Adding a new feature to 
| your program does not force you to use it. And if you added the 
| feature, you could avoid the need to rescale altogether by creating 
| some smaller bitmap pieces.

Like I explained above, I don't want to add too many features aimed at
doing the same task.

| That depends on the set. I would not use the same images for a 
| Japanese set, and my Symbolic set uses different images, but the 
| set I based on the Chess Motif font uses standard Chess piece images, 
| and it makes sense for this set to just change the color for the 
| promoted pieces.

I don't understand this. Promoted pieces in Shogi move completely
different from their unpromoted counterpart, so the symbol for a
corresponding standard Chess piece would be completely different. I would
think it made sense to represent pieces that move the same by the same
symbol.

| I would not know if this is true, because Winboard would not let 
| me make a single move when I tried to use it for Shogi.

This is strange. Was that because you could not select Shogi at all,
because you had no engine? If you click 'view or edit games' in the
startup dialog, you should not need any engne, and it sould accept all
moves. Be sure to use board size middling or bulky if you want to see al
the pieces, though, as for Shogi, not all sizes have built-in bitmaps.

H. G. Muller wrote on Thu, Oct 23, 2008 09:50 AM UTC:
| If it could. Otherwise, it might be enough to call an engine on 
| another server. But I do want to look into the possibility of 
| running an engine on the server. I know this website runs on a 
| FreeBSD server. Would Fairy-Max run on a FreeBSD server?

Fairy-Max is available in source (this is included in the WinBoard_F
download), and the source can be compiled both for Windows and Linux. You
have to define the macro LINUX to make it use a Unix-like call for reading
the clock. I suppose this would also work on FreeBSD.

| Right now, I need to know what the most basic steps would be. I need 
| to know where to put the engine, what protocol to use to communicate 
| with it, and how I could do this through PHP.

WinBoard engines are normal console programs that communicate in plain
text. So it is fairly easy to run them on another machine, using a remote
shell there to which GC connects.

H. G. Muller wrote on Thu, Oct 23, 2008 09:36 AM UTC:
M. Winther
| Muller, to get piece values at ~3% exactitude you would need to 
| presuppose that piece values are static properties. But they are 
| really changeable with regard to tactical and strategical context. 

Not necessarily. I always measure piece values in a well-defined context,
e.g. opening values, end-game values. Piece values are by definition
strategic quantities, I avoid starting in tactical positions, and for an
accurate measurement I average over many non-tactical initial positions
with similar peiece makeup. This usually gives quite consistent results,
when you keep the number of pieces and the total value of present material
approximately constant. (i.e. the difference of the performance of two
diffent pieces is hardly dependend on the details of the makeup of the
opponent or its allies.)

That piece values change as the board empties, because. e.g., Rooks get
more freedom of movement and Cannons can find fewer platforms, is
something that can be measured separately. If the piece values found for
the various qualitatively different situations differ, you can try to add
material-interaction terms in the evaluation. (The best known example of
such a term in normal chess is one proportional to the product of the
number of Bishops and number of Pawns, making the effective B-N difference
dependent on the number of Pawns.)

| This means that you would probably have to foresee the future in, 
| say, ten moves in order to get a ~3% exactitude. 

I am not sure what you mean by 'forsee the future'. By playing out the
game until checkmate or legal draw, I effectively make a Monte-Carlo
sampilng of all plausible futures. But it is important that the sample is
generated under conditions of reasonabe tactical accuracy, or you would
not be sampling a representative set of realistic positions, which then
would distort the results.

| One obvious example is XiangQi. Chinese Chess masters are hard pressed
| to reveal the relative values of pieces. Those pieces which are 
| completely lousy, like the elephant and the mandarin, are sometimes
| very valuable while they provide protection for the general, function 
| as screens for the cannon, or can block enemy pieces. So, in a certain
| context they become very valuable. 

I have not built an engine to play Xiangqi yet (I am in the preliminary
design stage now of an engine that could play Shogi, Chess and Xiangi with
arbitrary Chess men on boards upto 10x10.) So I have not done any
measurements for tuning. Quite possibly the material-interaction terms in
Xiangqi are much larger than in Chess, due to the peculiar capture mode of
the Cannon and the restricted access pieces have to the board. It seems to
me that the effects you describe can be described reaconably well by
cross-product terms of number of Cannons and number of other pieces. This
transcends pure piece values, but can be measured just as easily.

| Ten moves later, the elephant or mandarin is useless. Probably, in 
| chinese chess, only a human is capable of evaluating a piece.

Such a fast change is usually tactical, and then has little to do with
strategic piece values. Unles the strategic situation completely changed
in those ten moves, e.g. because all heavy material got traded, or all
hoppers got traded. But in that case such differences can easily be
expressed by terms that are proportional to the amount of heavy material /
number of hoppers.

I doubt if Humans could do this job better than computers. This is why I
would like to build a Xiangqi engine, so that I could do similar tests on
piece values as I am doing now for Chess.

M Winther wrote on Thu, Oct 23, 2008 04:38 AM UTC:
Muller, to get piece values at ~3% exactitude you would need to presuppose
that piece values are static properties. But they are really changeable
with regard to tactical and strategical context. This means that you would
probably have to foresee the future in, say, ten moves in order to get a
~3% exactitude. One obvious example is XiangQi. Chinese Chess masters are
hard pressed to reveal the relative values of pieces. Those pieces which
are completely lousy, like the elephant and the mandarin, are sometimes
very valuable while they provide protection for the general, function as
screens for the cannon, or can block enemy pieces. So, in a certain
context they become very valuable. Ten moves later, the elephant or
mandarin is useless. Probably, in chinese chess, only a human is capable
of evaluating a piece.
/Mats

🕸Fergus Duniho wrote on Thu, Oct 23, 2008 12:54 AM UTC:
|| I would like to start with integrating Game Courier with a game engine.

| If I understand you correctly, you would want this engine to run on the
| same computer that acts as server for GC.

If it could. Otherwise, it might be enough to call an engine on another server. But I do want to look into the possibility of running an engine on the server. I know this website runs on a FreeBSD server. Would Fairy-Max run on a FreeBSD server?

Right now, I need to know what the most basic steps would be. I need to know where to put the engine, what protocol to use to communicate with it, and how I could do this through PHP.


🕸Fergus Duniho wrote on Thu, Oct 23, 2008 12:40 AM UTC:
|| There's me for one. 

| The keyword in this phrase is 'one'... :-)

I can only speak for myself, but I doubt I'm alone.

| If there are other programs with graphics that you like better, then I 
| could only win you over by providing similar graphics.

No, that doesn't follow. You could win me over by providing better graphics. Besides, all I want is the ability for me to provide you with better graphics. I am not asking you to provide any additional graphics. I have the graphics. I want the ability to use them with Winboard.

| That would be a total waste of time, as I would be making something that 
| apparently exists already.

No, it would not be a waste of time at all. The only programs with the kind of graphics capability I want are Zillions of Games and a couple Chinese Chess programs with customizable graphics. Everything else comes up short, even ChessV, because it doesn't use images for boards.

|| I have a good Shogi program that came in a commercial suite that also 
|| includes Chess and Xiangqi, though I prefer other programs for those 
|| games, such as Chessmaster and Coffee Chinese Chess.

| Well, nice for you. Just play the Kamikze Mortal Shogi with that one, 
| then.

That is not an option. It is a commercial program that only plays Shogi and does not include any graphics for the Kamikaze piece.

|| Anyway, resizing boards is not as important as just allowing bitmap 
|| images to be used for boards and pieces. It makes a difference only 
|| for large variants that don't easily fit on the screen. 

| Well, it doe to me, and many like me: a I have a dual-core PC I play two
| games simultaneously, and would like to fit both WinBoard displays next 
| to each other, together with the control windows of the corresponding two
| tournament managers. And soon I will have a quad (or, when I get my way,
| even an octal core or dual quad)...

Since Winboard already supports fonts, you do have the option of using fonts instead of rescaled bitmaps. Adding a new feature to your program does not force you to use it. And if you added the feature, you could avoid the need to rescale altogether by creating some smaller bitmap pieces.

| Using the same image for the promoted and unpromoted piece is just bad 
| design of the piece set.

That depends on the set. I would not use the same images for a Japanese set, and my Symbolic set uses different images, but the set I based on the Chess Motif font uses standard Chess piece images, and it makes sense for this set to just change the color for the promoted pieces.

| By the same token you could represent all Chess pieces by
| Pawns, and then complain how essential it is to have their heas rendered
| in all different colors to distinguish a Knight from a Queen...

No, what works well in moderation does not always work well when taken to an extreme.

| The built-in winBoard representation does not suffer from this. Promoted
| pieces are clearly distinct from the unpromoted versions there. They look
| like the piece they promote to, while stil betraying their origin.

I would not know if this is true, because Winboard would not let me make a single move when I tried to use it for Shogi.


H. G. Muller wrote on Wed, Oct 22, 2008 10:43 PM UTC:
| There's me for one. 

The keyword in this phrase is 'one'... :-)

| I don't use Winboard, because it has poor graphics, and I don't think
| it yet supports any games I'm interested in well-enough that I can't 
| play with another program that has better graphics. 

Well, if that is your opinion then I am happy you do not use it. If there
are other programs with graphics that you like better, then I could only
win you over by providing similar graphics. That would be a total waste of
time, as I would be making something that apparently exists already.

I have absolutely nothing to gain by competing with other programs in
their own niches through mimicry. WinBoard is not a commercial program,
and I therefore don't care how small it user base is. What I care about is that it provides opportunities to its users that they cannot find anywhere else.

| For now, I prefer to use ChessV, which plays many games well and 
| includes some of my own graphics with it. 

I have no experience with ChessV, as it does not support automated play
against other engines. In the Unspeakable World Championhip 2007 it ended
well below Fairy-Max, but Gregory told me that this was an obsolete
version used without his permission, not representative of the strength of
current versions.

| I have a good Shogi program that came in a commercial suite that also 
| includes Chess and Xiangqi, though I prefer other programs for those 
| games, such as Chessmaster and Coffee Chinese Chess.

Well, nice for you. Just play the Kamikze Mortal Shogi with that one, then. But it is of no use to me, as the Shogi program is no doubt not capable of automated play against, say, TJshogi or GNUshogi, or to the Shogi engine I will be developing.

| Yes, probably because the poor graphics turn off those who care about 
| such things. My point is that you can expand your user base by allowing
| easier customization options for graphics.

Well, I have never heard any complaint about this before, and current
users are eager enough to complain about many other aspects they don't
like, so it doesn't seem to be true in general that perceived
shortcomings immediately deter them from using it.

| I'm no expert on how anti-aliasing is done. I just use a function 
| supplied by the GD library. But I can tell you it is done very fast, 

Very fast is a relative notion. Something that needs to be done 60
times in a 1-min game doe not have to be visibly slow before it starts to
soak up a sizable fraction (say 5%) of the CPU time. Correspondance Chess has other standards.

| and I expect Winboard would have to do only between moves, not when it
| needs all the CPU power for calculating a move. 

The problem is that in engine-engine games you always need all CPU power
for calculating move, as when it i not engine A's turn to move, engine B
should start thinking. Plus that these programs often want to think in the
opponent's time as well.

| Anyway, resizing boards is not as important as just allowing bitmap 
| images to be used for boards and pieces. It makes a difference only 
| for large variants that don't easily fit on the screen. 

Well, it doe to me, and many like me: a I have a dual-core PC I play two
games simultaneously, and would like to fit both WinBoard displays next to
each other, together with the control windows of the corresponding two
tournament managers. And soon I will have a quad (or, when I get my way,
even an octal core or dual quad)...

| Game Courier's boards and pieces are at a scale that normally fits 
| the screen for most games and usually don't need to be resized.

Yes, if you only want to have one game on screen, and not four.

| I'll still play Shogi, but if Winboard plays Shogi only with shoddy 
| graphics, I will play Shogi with another program. The issue here is 
| not whether people are sufficiently interested in Shogi but whether 
| your program would be a more appealing option than some other program.

Well, to some it is. To me it is. That is enough for me.

| Shogi is a good reason for including multi-color pieces. In Shogi, 
| the promoted sides of pieces are normally red rather than black. 
| This makes it easier to tell promoted pieces from unpromoted ones, 
| and it is crucial when you are using a westernized set in which the 
| promoted pieces use the same images as the unpromoted pieces.

Well, there is no red in the Japanese set I have, that's for sure. Using
the same image for the promoted and unpromoted piece is just bad design of
the piece set. By the same token you could represent all Chess pieces by
Pawns, and then complain how essential it is to have their heas rendered
in all different colors to distinguish a Knight from a Queen...
The built-in winBoard representation does not suffer from this. Promoted
pieces are clearly distinct from the unpromoted versions there. They look
like the piece they promote to, while stil betraying their origin.

H. G. Muller wrote on Wed, Oct 22, 2008 09:56 PM UTC:
To Rich:
Indeed, I think it is good to have diversity. There is no point whatsoever
in giving WinBoard and GC all the same capabilities, as one of them would
then be superfluous. The requirements for a GUI are entirely different
from the requirements for a game-play server. GC wil never make a useful
GUI for engine-engine play, and WinBoard will never make as versatile a
client to a server that can prepare html pages as a browser. In the areas
where the tasks they can perform overlap, it only enriches the world that
they are different. People can then choose what they like best.

I would very much like to have an easier way of scaling the size of the
display, but if it is computationally too expensive, the efficiency
requirement hould take clear priority.

I am a firm believer in the 'maximum flexibility, minimum usefulness'
principle. Therefore I refrain from trying to make WinBoard do everything.
If there are tasks that have too little in common with what there is now,
it would be of no benefit to cram those into WinBoard. I would, for
instance, never teach it the rules of Checkers, Othello or Go to make it
possible to use it as a GUI for those games. There is too little synergy
to make that pay off.

🕸Fergus Duniho wrote on Wed, Oct 22, 2008 09:53 PM UTC:
Before I invest in that, I would want to be sure that there are actually people that want to use this feature at all.

There's me for one. I don't use Winboard, because it has poor graphics, and I don't think it yet supports any games I'm interested in well-enough that I can't play with another program that has better graphics. For now, I prefer to use ChessV, which plays many games well and includes some of my own graphics with it. I have a good Shogi program that came in a commercial suite that also includes Chess and Xiangqi, though I prefer other programs for those games, such as Chessmaster and Coffee Chinese Chess.

The user base of WinBoard seems to be far more interested in the games they use it for, and how well and reliably it supports the rules of those, than in having multi-colored pieces.

Yes, probably because the poor graphics turn off those who care about such things. My point is that you can expand your user base by allowing easier customization options for graphics.

They don't use WinBoard for generating artwork to hang on their walls...

I don't use Game Courier or Zillions of Games for that purpose either, but I do like to use a nice looking board and piece set when I play a game.

The way you scale the entire board, if I could find similar function in the Windows graphics library, does sound like it might be very expensive. Doesn't anti-aliasing involve Fourier transforming the image back and forth? You would have to do that every time the board changes (i.e. every move). Anything CPU-intensive is a no-no in a GUI that run on the same machine as the engines. There are already people that are complaining WinBoard currently uses more CPU time than they can afford fo their purpose (wich is playing sub-second games).

I'm no expert on how anti-aliasing is done. I just use a function supplied by the GD library. But I can tell you it is done very fast, and I expect Winboard would have to do only between moves, not when it needs all the CPU power for calculating a move. Anyway, resizing boards is not as important as just allowing bitmap images to be used for boards and pieces. It makes a difference only for large variants that don't easily fit on the screen. Game Courier's boards and pieces are at a scale that normally fits the screen for most games and usually don't need to be resized.

I think the risk that there are people that say: 'I am not going to play Shogi, as the pieces have only a single color' is very small. They are either interested to play Shogi, and would do no matter what to achieve that, or they don't.

I'll still play Shogi, but if Winboard plays Shogi only with shoddy graphics, I will play Shogi with another program. The issue here is not whether people are sufficiently interested in Shogi but whether your program would be a more appealing option than some other program.

In fact there is a lot that can be done with just outline and inner color. The Xiangqi pieces you show are in fact just that. The outline and the (solid) piece symbol are one color, the inner regions another. The WinBoard system could easily handle that. You could have designed the Shogi pieces similarly.

Shogi is a good reason for including multi-color pieces. In Shogi, the promoted sides of pieces are normally red rather than black. This makes it easier to tell promoted pieces from unpromoted ones, and it is crucial when you are using a westernized set in which the promoted pieces use the same images as the unpromoted pieces.


Rich Hutnik wrote on Wed, Oct 22, 2008 09:24 PM UTC:
Wouldn't it be possible to be able to have a way for diverse systems to
chat and then everyone picks their own way they want to render the
interface for players? 

Just curious...

H. G. Muller wrote on Wed, Oct 22, 2008 08:58 PM UTC:
Fergus:
| We each have our preferences. In general, your program will appeal to 
| a broader base when it can accommodate more preferences than just your
| own. For example, Game Courier uses some graphics I don't like and 
| supports many games I have never become interested in, but it is more 
| popular than it would otherwise be because I didn't limit it to my own
| preferences.

Before I invest in that, I would want to be sure that there are actually
people that want to use this feature at all. The user base of WinBoard
seems to be far more interested in the games they use it for, and how well
and reliably it supports the rules of those, than in having multi-colored
pieces. They don't use WinBoard for generating artwork to hang on their
walls...

The way you scale the entire board, if I could find  similar function in
the Windows graphics library, does sound like it might be very expensive.
Doesn't anti-aliasing involve Fourier transforming the image back and
forth? You would have to do that every time the board changes (i.e. every
move). Anything CPU-intensive is a no-no in a GUI that run on the same
machine as the engines. There are already people that are complaining
WinBoard currently uses more CPU time than they can afford fo their
purpose (wich is playing sub-second games).

Although there i a general truth in the things you say, I still think it
is good to keep well-defined priorities. There is still so much that can
be done. I think the risk that there are people that say: 'I am not going
to play Shogi, as the pieces have only a single color' is very small. They
are either interested to play Shogi, and would do no matter what to achieve
that, or they don't.

In fact there is a lot that can be done with just outline and inner color.
The Xiangqi pieces you show are in fact just that. The outline and the
(solid) piece symbol are one color, the inner regions another. The
WinBoard system could easily handle that. You could have designed the
Shogi pieces similarly.

🕸Fergus Duniho wrote on Wed, Oct 22, 2008 07:45 PM UTC:
It seems that you have an application / need for the extra colors because you are not just displaying the piece symbols, but are actualy trying to create a realistic image of the game as it would be played with physical pieces.
Personally I don't think this is very desirable; I would prefer to play Shogi without th pentagonal outlines and Xiangqi without the circles.

We each have our preferences. In general, your program will appeal to a broader base when it can accommodate more preferences than just your own. For example, Game Courier uses some graphics I don't like and supports many games I have never become interested in, but it is more popular than it would otherwise be because I didn't limit it to my own preferences.

What software do you use to scale the GIF files? I always get excessively ugly reslults when I do that. Even when my browser scales a gif image of a Chess poition, separation lines between board squares are randomly disappearing, etc.

I use the GD library that comes with PHP. What I do is create a whole board image, then rescale that. I don't rescale individual pieces. The advantage to doing it this way is that I get in-context anti-aliasing of every piece with the space it occupies.


H. G. Muller wrote on Wed, Oct 22, 2008 05:29 PM UTC:
M. Winther:
| I bet you wouldn't be able to program certain of my most advanced 
| pieces in Fairy-Max.

As Fairy-Max is written in C, and C is a recurive language, and recursive
languages are equivalent to a Turing machine, and a Turing machine can
calculate anything that is calculable, you would lose that bet with
mathematical certainty!

Moves of Catapult pieces, for instance, are akin to castling moves, and it
would be fairly easy to built something into Fairy-Max that would allow
this type of 'castling'. If I had the motivtion to do it. The Catapult
pieces do not particularly appeal to me, as they violate what I consider
to be one of the defining characteristics of a Chess variant: that it
moves only one piece per turn.

Note that  am not in any way denying that what I do, could be done by Zillions. But the differences I want to measure do not result in 6-0 scores. A Pawn advantage in Chess results only in 18% advantage, and even less in Capablanca-type variants. I want to measure piece values to a precicion of at least a quarter Pawn, resulting in advantages of ~3%. To get the statistical noise below that I need 50-1000 games, so I cannot afford to let the engines spend half an hour on a game. They must play 1-min games, and play them at a sufficient high quality for the results to be meaningful. So I want the best engine I can get, and I doubt Zillions would qualify as such. But you can convince me by showing that Zillions can beat Fairy-Max in, say, Knightmate.

Rich Hutnik wrote on Wed, Oct 22, 2008 05:03 PM UTC:
Thanks you everyone for discussing this.

My interest in this is not in the minutia, or how everyone will get there,
just that we get there.  In this, my main interests is that everything
everyone is working on, will be able to work with one another (of course, I have a bias towards things being easy to do, but complete, so that whatever is decided upon will get used and adopted).  And, as we expand to cover more areas, everything together is able to handle it.  From an IAGO perspective, the system would not only be able to handle chess variants, but also stacking games (as seen Focus, and a chess variant I saw where pieces were made up of a stack of pieces), and games with piles or areas, like the Mancala family.

If we get interoperability right here, then you could have a case where
the CV site and its members could play against people on the Scheming Mind site, for example.

This is my concern here, and I hope whatever is reached is used.  I am
sure there are many paths to get to where one needs, the idea is to make
sure the paths work together.

In regards to Zillions, Zillions was an example of one program that could
work.  Something else could be used instead.  However, if one uses open
standards, someone may encode a plug in for Zillions to be able it to also work.  The open standards approach would enable GC to be integrated with by a LOT of engines, if the makes of engines and client programs know what the specs are to code to.  We can get one to work (say Axiom) and then others see it can.  They would then make their programs work also, and the CV site could get more people involved and greater traffic.

Just my 2 cents.  And thanks again for the input.

H. G. Muller wrote on Wed, Oct 22, 2008 04:44 PM UTC:
Fergus: | I would like to start with integrating Game Courier with a game engine. If I understand you correctly, you would want this engine to run on the same computer that acts as server for GC. WinBoard engines would typically allow what you want: you could sent them a list of (linefeed-separated) moves, after sending it the commands new variant setboard force g1f3 d7d5 (where the variant and setboard commands are optional, and can be omitted if you play normal Chess or start from the default array of the given varant, respectively). The 'force' tells it that you are just going to feed it moves for both sides, and don't want it to play any moves by itself. If you send an illegal move, i.e. something that does have valid move syntax of two concatenated squares, but is illegal according to the rules of the game in the current position, you will receive the answer Illegal move: where the offending input line is echoed back, so that you can determine where it goes wrong. If even the syntax is invalid, so that it is not recognized as a move, the complaint will be Error (unknown command): Engines do not prompt for moves, so if the move was OK you will receive no echo. If you want to make sure the engine has processed everything you sent it, before proceeding, you can send it 'ping ', where is any number. The engine will then answer 'pong ' when it is done processing, echoing the number back to you. WinBoard protocol does not define a way for the engine to transmit a position to the GUI, but a command making them do so can of course be added without detroying their WB compatibility. In fact all my own engines respond to the non-WB command 'p' by printing an ASCII board, for debugging purposes when I run them from the command line, rather than in a GUI. If you want the engines to provide a move, you would start the same way (sending variant name, position and moves) for loading the position, and then send time go to tell the engine how much time it has left on the clock, and that it should think up a move. You might have to give it a 'level' command at the beginning of the game to tell it how many moves it has to do in the given time. This sounds pretty close to what you want.

M Winther wrote on Wed, Oct 22, 2008 04:29 PM UTC:
Muller, in Zillions there is, among the standard games, a variant called
Fairy Chess. By right-clicking you can insert fairy pieces (e.g.
grasshopper) in a standard piece context, on an 8x8, or a 10x10 board. So
it's easy to create unequal armies this way. 

I have invented many interesting pieces of the catapult type, bifurcation, cannon variants, etc. You could always try to implement any of these pieces if you like them:
http://hem.passagen.se/melki9/chessvar.htm
There is also an implementation of diverse Capablanca variants there.

Piece evaluation in Zillions can be corrected by a tweaking method which I always use. The result is very good, but it's hard to tell if it's
perfect. The method has drastic positive results. I tested my
implementations of Chinese Chess and Korean Chess against the standard
Zillions versions. Almost the only difference was that I had tweaked the
pieces so that their value was corrected. The result was that my versions
won 6-0 in both matches. So it is possible to compensate for Zillions
deficiencies in piece evaluation. Remember that it is still a programmin
tool, and you can do much advanced programming. I bet you wouldn't be
able to program certain of my most advanced pieces in Fairy-Max.
/Mats

H. G. Muller wrote on Wed, Oct 22, 2008 04:13 PM UTC:
To Fergus:

It seems that you have an application / need for the extra colors because
you are not just displaying the piece symbols, but are actualy trying to
create a realistic image of the game as it would be played with physical
pieces.

Personally I don't think this is very desirable; I would prefer to play
Shogi without th pentagonal outlines and Xiangqi without the circles.

The Linux version of Winboard, xboard, does have the possibility to have
user-defined graphics called 'pixmaps', and I am not sure there is any
limitation on the number of colors that can be used in them. (They have
the undesirable property, however, that they represent square and piece
together.)

What software do you use to scale the GIF files? I always get excessively
ugly reslults when I do that. Even when my browser scales a gif image of a
Chess poition, separation lines between board squares are randomly
disappearing, etc.

H. G. Muller wrote on Wed, Oct 22, 2008 03:50 PM UTC:
M. Winther:
| Muller, which are the chess variants you are testing? Zillions is World
| Champion in several hundred chess variants. 

That does not really prove much about its strength if it was the only
contender... I have been testing games like Shatranj, Knightmate,
Capablanca, Superchess (as in Superchess & Monarch), Falcon Chess, Great
Shatranj. And I am testing many 'unofficial' variants consisting of one
or two unorthodox pieces embedded in a conventional setup, e.g. replacing
Knights with Cannons, Modern Elephants or Dababbas, or (pairs of)
Grasshoppers, Ferzes, Wazirs, Xiangqi Horses; Rooks with Nightriders,
Queens with Centaurs or Amazons. Usually in setups with different Armies,
on 8x8 or 10x8 boards.

| Rybka is only World Champion in one. Without Zillions, how would it be 
| possible to test and try Hexagonal Chinese Chess, recently invented by 
| L. Smith? It would take a century. 

Well, the game does not seem listed here, so it is hard for me to comment
on it. If I would be interested in it, I might configure Fairy-Max to play
it. If very exotic pieces that defy Fairy-Max' piece-definition format
would participate, and I was interested enough, I would hard-code the
particular piece in Fairy-Max, or add general support for the property
that made it impossible before. (I did this for the Falcon, for example.)
In general I am not so much interested in entire variants, as in
individual Chess pieces occurring in those variants.

| And it beats me easily in Xiang Hex when I try it. Zillions is
| very appropriate for 99% of all chessplayers. It's beyond me how 
| a person interested in boardgames can refrain from buying Zillions 
| at $20.

This is because I am not interested in playing against engines, but in
building them, and I already have developed engines that can do the things
I am interested in (piece value measurements) which I consider highly
superior to Zillions (w.r.t. playing strength). If I had teleport ability,
why would I buy a Rolls Royce?

M Winther wrote on Wed, Oct 22, 2008 02:26 PM UTC:
Muller, which are the chess variants you are testing? Zillions is World
Champion in several hundred chess variants. Rybka is only World Champion
in one. Without Zillions, how would it be possible to test and try
Hexagonal Chinese Chess, recently invented by L. Smith? It would take a
century. And it beats me easily in Xiang Hex when I try it. Zillions is
very appropriate for 99% of all chessplayers. It's beyond me how a person
interested in boardgames can refrain from buying Zillions at $20. 
/Mats

🕸Fergus Duniho wrote on Wed, Oct 22, 2008 01:45 PM UTC:

Since Shogi pieces are all the same color, here is another image from Game Courier, this time of Xiang Qi, whose pieces are different colors.


🕸Fergus Duniho wrote on Wed, Oct 22, 2008 01:13 PM UTC:
Fonts are better than bitmaps, because the bitmaps cannot be scaled.

Game Courier uses bitmaps and rescales them for JPG, PNG, and GIF boards.

I am not so sure about the desirability of having multi-colored pieces (on top of outline and two colors for defining the filler shading gradient). It seems to me that this would only degrade the ease of recognizing which side the pieces belong to.

I will answer this with a picture:

This picture was created by Game Courier from multi-color pieces, and it was also rescaled. The use of multiple colors allows the pieces to look more realistic. Basically, allowing multi-color images allows photographic quality pieces.


🕸Fergus Duniho wrote on Wed, Oct 22, 2008 01:04 PM UTC:
| Fergus:
|| Software standards for integrating Game Courier with a GUI or
|| a game engine would have to arise from an actual project of trying to
|| integrate Game Courier with some actual piece of software, and I would
|| have to work with the programmer on this,  ...

| Well, so WinBoard is the GUI, and I am your man! :-)

I would like to start with integrating Game Courier with a game engine. I have some ideas for how this can be done. First, Game Courier has its own programming language, GAME Code, and all calls to game engines would be done through lines of GAME Code. It would be coded into an individual preset whether it uses an external game engine.

The first thing a game engine would be used for is to check the legality of a move. When a player moves, a line of GAME Code would send the moves and any other information the engine needs to the external engine. Since this is done within the context of a GAME Code program written for a specific game, it would be easy to customize the information it gives to the engine, depending upon what the engine needs. An engine for one game only might just require the moves, while a more customizable engine might require more data. At the bare minimum, the engine would indicate whether all the moves passed to it are legal. With this confirmation from the engine, the GAME Code program could move the pieces around on the Game Courier board without checking the legality of the moves any further. Hopefully, the engine could give some detailed error messages when a move is illegal, such as mentioning the specific illegal move and explaining why it is illegal. If not, Game Courier could call the engine multiple times with longer sequences of moves, so that it can itself identify the specific illegal move. It's also possible that the engine could return FEN code, and some lines of GAME Code would just update the board to match the new FEN without actually performing the moves the player gave. This would allow the use of game specific notation that even Game Courier cannot understand.

The second thing a game engine would be used for is to play a game. As long as the engine moves fast enough, it could feed its moves directly to Game Courier when it gets called by the GAME Code. If its going to take longer, PHP might have a problem with the time it takes to get a response and stop execution before it returns a move. If so, another means will be needed to tell when the engine has moved, perhaps by using JavaScript.


H. G. Muller wrote on Wed, Oct 22, 2008 12:16 PM UTC:
'Zillions, on a modern computer, plays chess at, perhaps, Elo
2150-2200.'

That might be true against Humans in 5-min games, but I have strong doubts
that that has any bearing on how strong it is. Based on Zillions
performance in Gothic Chess I estimate its rating more round 1800 Elo.
When I had micro-Max play on the ICC server against Humans it also quickly
converged on a rating of 2260, but it seems that almost any computer
program, no matter how poorly it plays, does that. I once saw a report of
Tord Romstad, about his attempts to reduce the playing strength of his
engine Glaurung. At some point he had crippled it so much that it would
litterally score 0% against TSCP (an extremely weak engine, which
micro-Max would totally crush), and blundered away a piece or rook nearly
every other move. It still kept beating 2100-rated players on ICC!

Anyway, Zillions might suit your needs, it definitely does not suit mine.
I need computer opponents to test my engines, so it is not really relevant
how many variants Zillions plays, just that it plays the variants for which
I have built engines. And if even the most basic engine I build totally
crushes it, I can learn nothing from playing it against Zillions. My
reason for playing engines against each other is to test which one of
different versions is better. If all versions score close to 100%, I can
learn nothing from it. And if I would want to play a variant against a computer myself, I might as well configure Fairy-Max to play that variant.

Of course even if Zillions were strong enough, it would still be useless
to me, as it cannot play automatically against other engines at all...

Joe Joyce wrote on Wed, Oct 22, 2008 12:00 PM UTC:
Gentlemen, let me jump in here. I've been following the discussions on
standards with great interest and a greater lack of knowledge. But when I
see something 'dangerous' to design, I will say something. Here, I'm
very concerned about the idea of not using color for the pieces. I've
already done a basic game design that requires multiple colors per side,
have 2 games already using the pieces, and am working with another
designer to create a range of games that use these and similar pieces.
Honestly, I have been intending to add more and differently-colored pieces
to the Alfaerie:Many piece set. Heh, if this site stays up, I hope to post
some game pages over the next few days that will include large multi-move
games, some with multi-square pieces defined by color, like Chesimals I.

I appreciate programmers need cut-off points. But designers need freedom.
[I have actually discovered the hard way that game courier 'only'
accepts about 48 moves for one player in one turn.] The flexibility of
Game Courier is a beautiful thing. Please don't take any of that
flexibility away in the future. Expand it if possible.

M Winther wrote on Wed, Oct 22, 2008 11:47 AM UTC:
Muller, it's not always relevant to test a program against other programs.
Most chess programs beat 99% of humans. Nevertheless, they are smashed by
Rybka, and completely annihilated. Of course, Zillions loses against
stronger programs. But is it fun and developing to play against it? Yes,
it is. Zillions, on a modern computer, plays chess at, perhaps, Elo
2150-2200. It plays an entertaining game, too, advancing boldly with the
pawns on the wing, etc. I always tweak it to make pawn moves in the
opening, and discourage early queen excursion. Then it plays a rather
mature game. I am a good judge, because I'm a quite strong club player.
Moreover, Zillions understands all those strange new pieces better than
humans do. So it often wins by utilizing them better. It takes longer time for a human to develop a grasp of a cannon or a catapult, etc. Zillions is clearly the best way of testing chess variants, whether they are fun, whether they are interesting strategically, etc. Zillions is a remarkable tool for chess variants. People in the chess community are often interested in which program has the highest rating, but who cares? Zillions is actually the best chess program because it plays most variants.
/Mats

H. G. Muller wrote on Wed, Oct 22, 2008 11:26 AM UTC:
I think WinBoard uses the bitmap for the entire board, or tiles it if the
bitmap you have given is not big enough to cover the entire board. I did
not code this part myself, so I cannot give you the details off hand.
There are additional options /darkTextureMode and /liteTextureMode that
control if some additional randomization is done in the process of cutting
the squares out of the given bitmap. I am not sure how this works exactly,
I hardly ever use the texture modes, as I like evenly colored squares
better.

Fonts are better than bitmaps, because the bitmaps cannot be scaled. So
for every board size you would have to remake the bitmaps from scratch.
The font can be rendered at any size.

Fonts are indeed pure black/white constructs. The black defines the
outline, and any internal areas are filled with another color to get a
shading effect. The colors and shading are user-selectable. I am not so
sure about the desirability of having multi-colored pieces (on top of
outline and two colors for defining the filler shading gradient). It seems
to me that this would only degrade the ease of recognizing which side the
pieces belong to.

🕸Fergus Duniho wrote on Tue, Oct 21, 2008 02:06 PM UTC:
WinBoard can use arbitrary bitmap files for the square coloring

I once considered letting Game Courier use image tiles for making boards, but I eventually decided to just let it use a single image for the whole board. This is simpler to do, and it looks more natural than repeating the same pattern on multiple squares, especially when using marble and wood grains. Can Winboard specify an arbitrary image for each space, such that something like Smess or Storm the Ivory Tower would be possible?

The pieces cn be user-defined through the option /renderPiecesWithFont=... and /fontPieceToCharTable='...', which can be used to select any pictorial true-type font for piece rendering, and define the mapping of pieces to font symbols.

Using fonts is better than nothing, but it creates a stumbling block to developing images for use with Winboard. Although many piece sets are available, we don't have anyone ready to translate them into fonts, which leaves Winboard unable to use them. Also, I imagine that the fonts are normally greyscale line drawings, not full color images. This would prevent Winboard from using some of the nicer pieces I've designed.


H. G. Muller wrote on Sun, Oct 19, 2008 07:56 AM UTC:
M. Winther:
| Whoever said that isn't aware that there are tweaked Zillions chess
| variants programs that play a fine game of chess. 

Well, as I have no Zillions, I cannot test that. What (computer) rating do
you think Zillions would have in (properly tweaked) normal Chess? Could it
beat Fairy-Max / micro-Max? I doubt that very much, and Fairy-max is only a
very mediocre engine, (what can you expect from a mere hundred lines of
code?), about 500 Elo weaker than a good engine, and about 1000 Elo below
the World top (=Rybka).

From the unspeakable World Championship, where Fairy-Max beat Zillions, I
got the impression that Zillions is tactically weak. It just doesn't
search deep enough.

H. G. Muller wrote on Sun, Oct 19, 2008 07:49 AM UTC:
Fergus:
| Software standards for integrating Game Courier with a GUI or
| a game engine would have to arise from an actual project of trying to
| integrate Game Courier with some actual piece of software, and I would
| have to work with the programmer on this,  ...

Well, so WinBoard is the GUI, and I am your man! :-)

| Furthermore, my greater interest right now is in helping a GUI gain 
| moreof the capability of Game Courier, especially in graphics and in 
| the capacity to handle more types of variants. 

It has always been my aim to develop WinBoard in this direction, and I
think I already made a very good start at this.

| Zillions of Games has  a great interface, but it is too weak for many
| games, especially Shogi-like games. 

Agreed. The level of Zillions is probaby perfect for beginners, but it is
no match for dedicated engines. And especially piece drops are a weak spot
in its search algorithm.

| My special interest is in having a strong Shogi program that can use 
| the graphics I have designed for Shogi and which can handle some of my |
Shogi variants, such as Kamikaze Mortal Shogi and the Hex Shogi games.

Building a Sogi engine is one of the things on my to-do list. I decided to
re-write my Chess engine Joker (and have actualy started working on that)
in such a way that it is more friendly to implementation of variants, e.g.
using a 10x10 board as basis (so that 8x8, 10x8, 9x9 and 9x10 can be
implemented as a subset, by filling a larger part of the internal 16x16
board with edge guards, besides the 3-wide guard band). Adding piece drops
to that would be a very good basis for a strong Shogi engine.

H. G. Muller wrote on Sun, Oct 19, 2008 07:25 AM UTC:
Fergus:
| How does that work? Does WinBoard allow the use of graphic images for 
| pieces? Game Courier allows the use of GIF images for pieces. Does it 
| allow any customization of the board's appearance? Game Courier allows
| GIF, PNG, and JPG images for boards, and it can draw multiple kinds of 
| boards. If WinBoard can use images for boards and pieces, then I would 
| be happy to contribute some.

WinBoard can use arbitrary bitmap files for the square coloring (through
options /liteBackTextureFile=... and /darkBackTextureFile=... on the
command-line or in the winbord.ini file. For some examples, see:
http://usuarios.lycos.es/alexwbtm/Test/ or
http://www.open-aurec.com/wbforum/viewtopic.php?t=49439 (bottom).

The pieces cn be user-defined through the option /renderPiecesWithFont=...
and /fontPieceToCharTable='...', which can be used to select any
pictorial true-type font for piece rendering, and define the mapping of
pieces to font symbols. A good example of this would be the Superchess
font obtainable from http://www.superchess.nl.

M Winther wrote on Sun, Oct 19, 2008 05:02 AM UTC:
>>I don't have Zillions, and I do not have the slightest interest 
>> in buying it, as it plays like cr*p.

Whoever said that isn't aware that there are tweaked Zillions chess
variants programs that play a fine game of chess. The problem is, namely,
that Zillions tends to move about with knights too much in the opening,
and develops the queen too early. It also sometimes misjudges the value of
the pieces. It moves the king to the corner too readily. But all this can
be easily corrected by tweaking. I always do this in my implementations:
http://tinyurl/chessvariants

One example is my implementation of Chinese Chess. It plays much better
than the standard implementation while the latter greatly overestimates
the value of the cannon compared with the rook, and underestimates the
Elephants and the Mandarins. It values them according to mobility, so they
get a too low value. But in Chinese Chess their blocking capability, king
protective capability, and their functionality as screen for the cannon,
give them a higher value. So one must tweak them to give them a higher
value, otherwise Zillions can't simply play correctly. That's why I
asked Larry to tweak the pieces in his Xiang Hex.
/Mats

Rich Hutnik wrote on Sun, Oct 19, 2008 04:25 AM UTC:
Hello Fergus.  I want to comment here:
1. There ARE programs out there that can benefit from this, and websites. 
On the programming front, there is Axiom (and Zillions), ChessV,
Cyberboard, and Winboard.
2. You are touching on a chicken and egg issue if you were to go with
'there is no software out there'.  Well, unless there is standardized
protocols, you aren't likely to see programs created specifically for
that.  And unless the programs are out there, then sites go they aren't
going to bother.  All this then becomes an excuse for not doing anything.
3. As for AIs being poor, well not sure what that has to do with providing
a GUI for people to be able to play over a server against other people. 
What I will say is, if you develop the communication protocols to enable
interoperability, using what is out there now (see names above), then you
will provide a place for people to work on AIs that are stronger.  They
could even work with Axiom to be able to code up stronger AIs.

So, things are out there now.  What is needed is to get them to work, and
not have people make excuses to justify the way things are today.

Also, if you do want to work with a developer on this, please contact me at: rich [at] iagoworldtour.com or richardhutnik [at] optonline [dot] net.   The developer of Axiom (Greg Schmidt) is working with Aaron Dalton of the SDG site to get Axiom to interface with his site.  It is in discussions now.  It would be helpful to email me, and I can get you the link to the forum, and also their email addresses, so this can come about.

So, in a nutshell, there are things afoot now, and getting Game Courier to also tie in and work would helpful.

🕸Fergus Duniho wrote on Sun, Oct 19, 2008 01:58 AM UTC:
Rich,

I think it is putting the cart before the horse to try to define software
interoperability standards before there is any software using them.
Software standards need to arise out of actual software, as Standard C
arose from the original Unix C, or as ECMAScript arose from the original
JavaScript. Software standards for integrating Game Courier with a GUI or
a game engine would have to arise from an actual project of trying to
integrate Game Courier with some actual piece of software, and I would
have to work with the programmer on this, not with someone who is just
spinning ideas and not doing any programming.

Furthermore, my greater interest right now is in helping a GUI gain more
of the capability of Game Courier, especially in graphics and in the
capacity to handle more types of variants. Zillions of Games has a great
interface, but it is too weak for many games, especially Shogi-like games.
My special interest is in having a strong Shogi program that can use the
graphics I have designed for Shogi and which can handle some of my Shogi
variants, such as Kamikaze Mortal Shogi and the Hex Shogi games.

🕸Fergus Duniho wrote on Sun, Oct 19, 2008 01:17 AM UTC:
I don't have Zillions, and I do not have the slightest interest in buying it, as it plays like cr*p.

Perhaps you are unaware that Andreas Kaufmann wrote a Winboard Adapter for Zillions of Games.


🕸Fergus Duniho wrote on Sat, Oct 18, 2008 11:04 PM UTC:
Fergus:
| Game Courier already has better graphics than the GUIs I've
| seen, such as Winboard ...
This cannot be true by definition, as WinBoard allows the user to define any piece anyway he wnts it to look...

How does that work? Does WinBoard allow the use of graphic images for pieces? Game Courier allows the use of GIF images for pieces. Does it allow any customization of the board's appearance? Game Courier allows GIF, PNG, and JPG images for boards, and it can draw multiple kinds of boards. If WinBoard can use images for boards and pieces, then I would be happy to contribute some.


40 comments displayed

LatestLater Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.